Subject: Minutes of HPR SIG at AIW 4

From: "Ray Bird" <[email-masked]>
Date: Tue, 8 Mar 94 16:38:07 EST

The following is a summary of the HPR SIG meeting held 2/18/94 at AIW4.

  o   How is a path switch communicated to the other endpoint?

          A Routing Information segment (in the THDR) is sent to indicate to
          the partner that a new path is being used.  When the partner receives
          it, it begins using the new path immediately.  If both partners send
          Routing Information at the same time, the winner's (i.e. the partner
          that activated the RTP connection) path is used.  Note that path
          information (RSCV, ANR) is associated and maintained for each RTP
          connection (TCID).

  o   Error in Frame Relay format for HPR NLPs when not using link-level error
      recovery (A.2.2, page A-35 of Sept. 24 APPN HPR Draft Document).

          The L2 Protocol Identifier should be X'5081' instead of X'7081'.

  o   Limited resource links

          Intermediate nodes have no knowledge of RTP connections (because they
          are just doing ANR routing).  So intermediate limited resource links
          are deactivated when no traffic flows over them for a specified time
          interval.  RTP connection endpoints send liveness messages which
          serve the purpose of keeping the intermediate limited resource links
          up while the RTP connection is active.

  o   RTP connection rerouting back to primary path when it becomes available

          An RTP connection can be manually rerouted back (e.g. operator
          control at RTP endpoint nodes).  There is no architecture to do it
          automatically.

  o   How do I know when to bring up a new parallel RTP connection?

          Reuse existing RTP connection only if the (new) session requires the
          exact same path and priority; otherwise, bring up new RTP connection.

  o   How do flow controls ARB and session pacing interrelate?

          When running sessions over an RTP connection, ARB will perform con-
          gestion and flow control.  Doing additional pacing for each session
          is not necessary for flow control BUT is necessary for providing
          fairness by preventing individual sessions from dominating the RTP
          traffic.

  o   FID5 PIU operation

          The difference between FID5 and FID2 is the session address.  The
          FID5 session address is 4 bytes long (the high-order bit indicates
          whether the address was assigned by the sender or receiver; the
          remaining 31 bits are the actual address), and can be used to index
          the correct session or may even contain the address of the control
          block (because control blocks are on at least 4-byte boundaries the
          low-order 2 bits of the addresss are always zero so only 30 bits are
          actually needed).  This 4-byte address avoids the 3-level FID2
          session address lookup (i.e., ODAI, SIDH, SIDL).  The nodes con-
          taining the RTP connection endpoints translate FID5 to FID2 and vice
          versa.

          A suggestion was made to consider expanding the field to make imple-
          mentations easier.  This will be considered.

  o   How does padding and 4-byte alignment in the RTP THDR and control vectors
      work?

          Rules on HPR RTP optional segments and control vectors:

          1.  All optional segments and control vectors (CVs) including
              embedded CVs (i.e., CV embedded within a CV) always start on word
              boundary, that is they're all 4-byte aligned.

          2.  Each RTP optional segment contains a length and a key field in
              the first 2 bytes.  The length field indicates the number of
              words of the segment (the length in bytes is equal to segment
              length times 4).  The actual length of the segment can be less
              than the length specified, therefore up to 3 bytes will be padded
              at the end of the segment.

          3.  Each CV embedded in the RTP header contains a length and a key
              field.  The length indicates the actual number of bytes of the
              CV.  If a CV follows (NOT embedded) another CV, and the preceding
              CV length is not on word-boundary (length is not divisible by 4),
              up to 3 bytes will be padded to make sure the following CV starts
              on word- boundary.  The padded bytes will NOT be included in the
              length of the preceding CV.

          4.  If a CV contains embedded CVs, all embedded CVs will follow rule
              #3.  The length of the outer CV will include the padded bytes
              BETWEEN embedded CVs, but NOT the ones (if any) required at the
              end to start the next CV on word boundary.

  o   Questions on SAP 04 / SAP C8

          The link is activated using SAP 04 (i.e. XID3 is sent using this
          SAP).  In the XID3, an additional SAP (default of C8) is specified
          that is used when sending NLPs that require no link-level error
          recovery.  Note that FID2 PIUs always use the APPN SAP 04 even when
          they flow on the same link as NLPs.  The default value C8 was picked
          from a "reserved" group of IBM SAPs.  There is an implicit agreement
          that other companies won't use these IBM reserved SAPs.  Strictly
          speaking, we don't need the C8 default since a SAP is exchanged on
          XID.  However, it is preferable for all products to use the same
          default value for network management reasons (e.g. debuggability).

  o   Why are PIU blocking and frame blocking not supported?

          There have been no requirements to do this function.

  o   When labels are stripped, are CRCs recalculated?

          Every link does CRC just as in today's APPN (HPR supports existing
          hardware).  Therefore when labels are stripped, a new CRC is calcu-
          lated by the outbound link.

          How does this affect performance?  ANSWER: It's not a limiting
          factor.

  o   Why is there a delimeter at the end of the ANR field?

          If we ever need to scan the string (debug?) we need it.  This pre-
          cludes using 'FF'x anywhere in any ANR label.

  o   How is the ANR string passed?

          On the route setup reply, not the RSCV.

  o   Please clarify TCID and NCE - why all these layers?

          The NCE may be used to route packets internally (e.g. to adapters)
          within the box.  Products not requiring this function can assign a
          single constant NCE value for the entire node.

  o   Why do we request status when sending ARB message?

          That's the only way to guarantee reliable delivery of the ARB
          message.

  o   How large is the byte-sequence number and will it wrap?

          A byte sequence number is a 32-bit mod 2**32
           number; i.e., the number space wraps with the sequence number 0 fol-
          lowing the sequence number 4,294,967,295 (X'FFFFFFFF').  Each byte of
          user data is assigned a byte sequence number.

          Each RTP partner maintains sequence-number windows of acceptable byte
          sequence numbers for its send and receive functions.  The size of a
          sequence-number window is always fixed and equal to 2**31.
          This means that the sequence-number window size is half the range
          of the byte sequence numbers.  The sender's sequence-number window
          starts at the Received Sequence Number (RSEQ) of the last Status
          segment received from the partner and ends at byte sequence number
          [(RSEQ + 
2**31 - 1) MOD 
2**32].
          At the start of an RTP connection, RESQ is zero until a Status
          segment is received; therefore, the sender's sequence-number window
          starts at 0 and ends at (2**31) - 1.
          The sender can only transmit or retransmit message bytes with byte
          sequence numbers within its sequence-number window.

          The receiver's sequence-number window starts at its RSEQ and ends at
          [(RSEQ + 
2**31 - 1) MOD 
2**32].
          The receiver's sequence-number window corresponds to the message
          bytes it is permitted to accept.  If the receiver receives a message
          byte with a byte sequence number outside its sequence-number window,
          it simply discards it.  This mechanism protects the receiver from
          ever accepting a duplicate message byte.

  o   Please talk about Bandwidth Manangement.

          HPR doesn't do any.